The zip code file was prepared by Brian Chaumer. He was kind enough to copy the file from the Master tape distributed by the US Postal Service, and send it to me. In return for this great favor, I have researched the copyright status, and obtained permission from the Postal Service to upload the file to CIS. It is current as of Feb. 1988. There only restriction is that it cannot be sold, but must be distributed freely. This only applies to the master file. There is not restriction with what you do with the data once you include it in a database.
The file is a tab delimited text file. It can be easily imported into any database or file management software. It consists of 3 fields in the following order - the zip code, the two letter state code, and the city. The city names and state codes are all uppercase.
I have use the program mainly to extract lists of zips so I can pre-configure copies of my database with the localized zip codes of the purchaser. To do this, I do a search based on the state(s) that need included in the customers database for their zip code look up file, and then export those.
Because 4D tends to be slow in exporting and searching, I decided to use Filemaker+ for the job. (This does not mean that FM+ is faster - I just assumed it to be true from all the hype. It could very well be that 4D is faster! Someone that imports the entire database into a 4D file might want to time it. There are 40,000+ records in the file. It took about one and one-half hours for FM+ to import it. FM+ can search and find a particular state in well under a minute however, and creates an export file very quickly. I then import the new file into the 4D database.
A small 4D database would handle this as well. To speed things up, create your import layout without a layout procedure. Then do the import by writing a global, rather than the import function in the user environment, so you can control the flush variable.
By setting the flush variable to 0, 4D only flushes the disk buffer when it is full. Otherwise it flushes it after every record is saved. By setting the flush variable to 0, your import time and export time will be reduced by about 1/2.
If you 4D database is strictly to handle this file and you don't want to bother with a full blown global, I think you could create two simple global procedures, FlushOff, which contains one line - Flush:=0, and FlushOn Which contains Flush:=1. Then you could execute the FlushOff procedure from the Execute procedure menu command in the User environment, then import the file with the import choice. After words, execute the FlushOn procedure to turn flush back on. I'm pretty sure that once you set flush to 0, it remains that way until explicitly reset to 1, or you end the program and restart.
Be sure you have your import layout fields in the correct order, and do not index any of the fields, or this will also slow 4D down.
You might wish to write a routine that will convert the uppercase city names to standard Upper/lower case notation. You could handle this several ways.
Personally, I put this in the input layout procedure for my destination database, where I'm typically importing only about 400 to 1000 records rather than 40,000 plus. It slows down the import a little, but its tolerable.
I suppose you could write a routine that would start with record 1 and step through the whole file, changing them. Start the procedure when you head home for the day, and the next morning when you get to work, it should be about done.
I hope you get some benefit from the file. I know that several of my potential customers were very excited when I told them that they would hardly ever have to type in a city and state, and if they did, it would only be once.
